1. Field of the Invention
The present invention relates to the field of object oriented application programming environments, particularly for applications accessing databases.
2. Background Art
Object oriented programming languages are non-procedural programming languages in which program elements are viewed as objects that can pass messages to each other. An object includes its own data and programming code and is internally self-reliant. The programming code of an object includes procedures or methods. The methods of an object are invoked by messages received from another object. Each object is an instance of an object class. The properties of the objects in a class are defined by a class definition. A class definition may utilize a hierarchical class structure in which objects in the class inherit properties of a parent class in addition to properties explicitly defined for the class. This inheritance property allows code for object classes to be customized for reuse in different applications, facilitating the sharing of programming code between different programs.
To write an application program in an object oriented programming language, a programmer identifies the real-world objects of a problem, the data and processing requirements of those objects, and the communications needed between the objects, and encapsulates these in class definitions. This process is simplified by taking advantage of the inheritance property of object classes by basing the class definitions to the extent possible on preexisting object classes.
Objects are assembled in a modular fashion to create applications. Objects call on other objects to perform operations or procedures by sending appropriate messages. An appropriate message is a message to which the receiving object can respond. The sending object must therefore know the type of functions that a receiving object can perform and be able to generate the corresponding message that will invoke the desired operation. The sending object must also be prepared to accept and process any resulting response.
Although objects are generally internally self-reliant, and can therefore be viewed as modules that can be assembled with other objects into a variety of application programs, the simple assembling of objects does not create a functional program. The objects must also be able to properly interact and intercommunicate with each other. Although objects represent reusable code, additional code must be written to provide for the generation of appropriate outgoing messages and for processing and responding to incoming messages.
One type of application program that is commonly used in business is a database application program. A database application program is a program that manipulates data stored in a database. The database is often managed by a separate program, called a database management program, which has the ability to respond to requests to store, retrieve, search for, extract and update data in the database. In order to access data in the database, the database application program must generate appropriate database requests to the database management program.
There are many types of database structures and many kinds of database management programs. In order to be able to access a particular database, a database application program must know the structure of the database and the syntax used by the database management program. As these can vary from one database to another, a single database application program cannot generally be used with different databases. Instead, separate versions of a database application program are needed to deal with different databases and different database management programs.
Two types of database structures are flat file databases and relational databases.
A flat file database can be viewed as a single large table having a number of rows and a number of columns. Each row (“record”) corresponds to a particular entity, and each column of that row (“field”) corresponds to a particular attribute of that entity. For example, an employee database may contain information about employees, including name, address, social security number, salary, department, etc. Each row would correspond to a particular employee. Separate columns would correspond to name, address, social security number, salary, department, etc., respectively. One of the columns contains an entry that uniquely identifies each row. This entry is often called the “primary key”. For the employee database example, the primary key might be the employee's name, the social security number, or an index number generated by the database management program. To find the salary for Jane Doe in the employee database, for example, one would look in the row corresponding to Jane Doe, and read off the salary in the salary column. In a flat file, the only data available about an entity is the information contained in the row corresponding to the entity, that is, only the information for which there is a column, or “field”, in the table.
In a relational database, information in one table may be related to information in other tables. For example, a company database may include an employee name and address table that contains a row for each employee, with fields for the name and address of each employee in each row. The database may also contain a departmental table that contains a row for each department, with each row containing a department ID field as well as fields for the names of all employees in the department. The departmental table may be linked to the employee-name and address table by including a field for the department ID in the employee name and address table. This department ID, called a “foreign key”, may be viewed as a pointer from the employee name and address table to the departmental table, indicating where additional related data may be found.
An example of a database application program that might use the relational database described in the preceding paragraph is an application that compiles the names and addresses of all employees of a particular department. This application might operate as follows. First, the application program requests the database management program to extract the names of all employees in the department in question from the departmental table. To do so, the application program needs to know the structure of the departmental table, and needs to formulate the request in the specific syntax of the database management program. Then, for each employee name obtained, the application program requests the corresponding address from the employee name and address table. Again, the application program must know the structure of the name and address table and needs to formulate the request, or in this case the series of requests, one for each employee name, in the correct syntax. The application program then needs to assemble the received data into a coherent form and display it to a user. The application program for even this simple function is complicated: the program must know about the structure of the tables in the database, must be able to generate a variety of database requests in the particular syntax of the database management program, must be able to process the data received, and must be able to assemble the data and display it on a user interface.
Database application program writing may be simplified by using object oriented-programming techniques. Objects can be constructed that perform input and output functions such as requesting data from a database manager program or displaying data on a user interface. An application program therefore need not be provided with code for handling these lower level functions. The application program can let appropriate objects take care of these and other requirements. Writing the application program is simplified.
Object oriented programming environments provide tools to programmers such as predefined object classes that can simplify the building of applications.
One prior art set of tools and resources for an object oriented programming environment that can be used to build database applications is Enterprise Objects Framework 1×™, a set of tools and resources for the NEXTSTEP™ object oriented programming environment from NeXT Computer, Inc.
The architecture and data flow of an Enterprise Objects Framework 1× application is shown in FIG. 1. In the application shown in FIG. 1, data flows from a relational database 100 to a user interface 160, and vice versa, via a number of intervening modules and levels. Each of the blocks shown in FIG. 1 constitutes a portion of the overall application program and may be made up of one or more objects.
The flow of data from the relational database 100 to user interface 160 proceeds as follows. Data in the form of rows of data from relational database 100 are retrieved from relational database 100 to an adaptor level 110, using well-known relational database access techniques. At adaptor level 110, the raw data received from relational database 100 is packaged into “dictionary objects.” Dictionary objects contain key-value pairs: each key typically represents the name of a database column, and the key's value corresponds to the data for the column of the particular row that was read from relational database 300. As shown in FIG. 1, data in the form of these dictionary objects is passed from adaptor level 110 to database level 120.
Database level 120 creates “enterprise objects” from the dictionary objects. Enterprise objects are like other objects used in object oriented programming languages in that they couple data with methods for operating on that data. However, under Enterprise Objects Framework 1×, an enterprise object has certain characteristics that distinguish it from other object classes. An enterprise object has properties that map to stored data, and an instance of an enterprise object typically corresponds to a single row or record in a database. Further, an enterprise object knows how to interact with other parts of the Enterprise Object Framework to give and receive values for its properties. The ingredients that make up an enterprise object are its class definition and the data values for the row or record to which it corresponds. The enterprise object also contains pointers to other enterprise objects created from rows of related database tables. These other enterprise objects typically contain vet other pointers to other related objects. The entire set of enterprise objects used by an application program thus forms an interconnected graph of data bearing enterprise objects. This graph constitutes a particular view of the underlying database.
The enterprise objects created at database level 120 are passed from database level 120 to data source 130. Data source 130 is an object that has the ability to fetch, insert, update and delete enterprise objects. As such it is both a source and a sink for enterprise objects. Changes made by data source 130 to an enterprise object are passed down via database level 120 and adaptor level 110 to relational database 100 so that a corresponding change is made to the database for a change made to an enterprise object. The data source 130 does not know the structure of the underlying database. Those details are taken care of by adaptor level 110. Accordingly, as long as the appropriate adaptor 110 is used, the same data source 130 can be used for a variety of different databases.
Data source 130 supplies enterprise objects created at database level 120 to controller 140. As shown in FIG. 1, controller 140 transports data in the form of values from the enterprise objects to user interface 160 via association objects 150. Controller 140 coordinates the values displayed in the user interface with the corresponding enterprise object values. When enterprise objects are modified in the user interface, controller 140 tells data source 130, which is responsible for propagating changes to relational database 100.
In Enterprise Objects Framework 1×, changes to enterprise objects must be made by editing values in the user interface or by using the controller method “setValues:for Object:.” Because enterprise objects typically include the business logic needed for the application, it would be useful if enterprise objects could be worked on by an application program in the same way most objects are worked on: i.e. by sending an enterprise object an appropriate message. However, because the integrity of the underlying database must be maintained, certain procedures performed on enterprise objects, such as procedures that make changes to the data in an enterprise object, must be specially handled. For example, changes made directly by sending a message to an enterprise object in Enterprise Objects Framework 1× bypass controller 140. Accordingly, as controller 140 controls messages to the user interface 160 and the database level 120, these changes are not updated in the user interface and are not saved in the database. In order for these changes to propagate to the user interface and the database, the enterprise object itself must keep track of changes and must explicitly notify controller 140 when changes occur. This requirement requires additional code in each enterprise object, making the building of enterprise objects, and applications using enterprise objects, more complicated and time consuming than other kinds of object oriented programming.
Another limitation of Enterprise Objects Framework 1× is that because controller 140 is tightly coupled to user interface 160, controller 140 is not usable for database server and other non-user interface applications. Accordingly, buffering and undo functions that are implemented in controller 140 in Enterprise Objects Framework 1× are not available for applications written for server platforms.